Declarative Meta languages have been promoted heavily in the information technology industry since the early 1990s by industry leaders such as Microsoft, IBM, and Sun Microsystems. Since that time, an increasing number of systems and applications have adopted the use of Meta languages. One of the Meta languages, XML, has become the de facto standard.
One use for which Meta languages have been proposed is legality expressions. Legality expressions are syntactically and semantically correct constructs based on a defined grammar. Legality expressions are the manifestation of a legality statement in digital form. The semantics of legality expressions may include assertions, certifications, permissions, obligations, prohibitions, intentions, promises, exclusivities, declarations, rules, rights, conditions, and policies. Legality expression “semantics” refer to the meanings of the legality expression. The “syntax” of legality expressions is another key component and refers to the data types and the structure in which words or expressions are put together to form phrases or clauses.
By themselves, Meta languages typically do not carry machine-interpretable semantics. However, there has been great industry demand for machine-interpretable semantics to automate business transactions and to facilitate interoperability across devices, platforms, and systems. Driven by this demand, enterprises and industry standard groups have developed legality expression grammars to overlay a Meta language. These grammars capture the semantics of legal expressions. Analogous to the relationship between a clause and the grammar in a natural language, a legality expression is a specific clause based on and compliant with the legality expression grammar.
Examples of legality expression grammars include, but are not limited to, the eXtensible rights Markup Language (XrML), the ISO MPEG Rights Expression Language (MPEG REL), the Open Digital Rights Language (ODRL), the Open Mobile Alliance (OMA) REL, the Content Reference Forum Contract Expression Language (CRF CEL), the Security Assertion Markup Language (SAML), the XML Access Control Language (XACL), the eXtensible Access Control Markup Language (XACML), the Business Process Execution Language (BPEL), and the Process Specification Language (PSL). Examples of legality expressions include XrML licenses that govern the use of Microsoft RMS-enabled Office documents, XML licenses that govern the use of Digital Rights Management (DRM) enabled Windows Media content, SAML assertions in Web Services applications, CEL-based eContracts for CRF-targeted business scenarios, and the like. This list of legality expression grammars is not inclusive, but instead shows examples of legality expression grammars well known in the industry.
Legality expressions may be used in a wide variety of systems and applications. Some examples include agreements between business entities, permissions granted by rights holders to distributors and consumers, policies and rules governing computer system behaviors, digital identification, digital certificates, tokens that assert an entity's identity and attributes, tokens that assert an entity's privileges in a government or enterprise security environment, and the like.
The primary objectives of legality expressions are to facilitate human-to-machine and machine-to-machine communications, and to enable precise and unambiguous machine interpretation. In other words, the syntax and semantics of legality expression grammars are typically not designed for an optimal real-time processing response. Transformation of the original legality expression format into a machine-internal representation is often required to detect the intent of a user from the semantics (meaning) and syntax (arrangement) of the legality expression.
In addition, it is conventional to impose digital signatures on legality expressions to authenticate their integrity. For privacy protection, legality expressions may be further protected by cryptographic means such as encryption. To mitigate size, bandwidth, and other constraints, legality expressions may be encoded in different formats. For example, a legality expression may be encoded in a binary format to reduce its size in the mobile communication environment. The transformation, digital signature, security protection, encoding, and other potential formatting all introduce additional overhead to the processing of legality expressions.
As grammar-based legality expressions become the prevalent means for communicating and enforcing legality terms on machine-interpreted and enforced transactions, many systems and applications may need to process large volumes of legality expressions efficiently. For example, a consumer's personal computer may contain thousands of licenses, each of which governs the use of one specific digital work or a group of digital works. In another example, a rights clearance center may manage and process millions of electronic licenses and contracts in response to frequent queries. In a third example, a large retailer may implement an automated contract issuance and management system that stores the contractual agreements between itself and its hundreds or thousands of suppliers expressed in a CEL. This application would require a gigantic database of eContracts. In addition, there are many instances where a legality expression management system needs to satisfy a fixed response-time requirement. For example, it may need to deliver authorization tokens for viewing a streaming video to the consumption device every second. A lengthy search for the appropriate permissions and usage rights would not be a practical solution in this environment.
In a conventional legality expression processing system, legality expressions are stored sequentially in a persistent repository. The stored legality expressions are captured in the original Meta language syntax. In certain cases, the legality expressions may be binary encoded, digitally signed, security protected, and formatted by other means.
Triggered by a processing request, the system processes the legality expressions in a linear fashion, typically going through the following steps of first selecting the legality expressions relevant to the processing request. The processing request typically encompasses a specific context. For example, a request might impose the query, “Does music distributor X have the permission from record company Y to sell its content in territory Z?” In this case, “X”, “Y”, “Z”, and “sell” can all be used as filters to select the relevant legality expressions. In other words, this specific processing request is only interested in the legality expressions that satisfy these four filtering criteria. Depending on the type of processing request, the system may need to find the first legality expression that matches the query, a subset of legality expressions that match the query, or all legality expressions that match the query.
Second, the legality expression is validated. The set of matching legality expressions from the “Select” step must be validated and verified. This may include reversing the binary encoding process, decrypting, verifying digital signature to confirm integrity, and validating the syntax of the legality expressions against the grammar.
Third, the legality expression is interpreted. This step extracts the semantic meaning from the legality expressions to construct the information needed for a response to the processing request. This step may also involve retrieving and processing other related legality expressions needed for the response. For examples, a usage right may only be granted if the principal possesses another (prerequisite) right. A legality expression can have one or more other rights or legal obligations requiring interpreting many layers of authorization, authentication, and the like. In this case, the system must search for and verify that the principal does possess the required pre-requisite right before granting the usage right.
Last, the system responds to the processing request. Once the initial steps have been completed, the system must determine that all conditions and obligations are satisfied in order to properly respond to the processing request.
These operations can be computing-resource and processing intensive, especially when the legality expressions are complicated, lengthy, or dependant on other legality expressions. Without a systematic method to organize and manage high volumes of legality expressions, it will be very difficult, and in some instances impossible, to respond to query, event, authorization, or other processing requests within a reasonable time. If the legality expressions are stored sequentially in a conventional storage area, looking up the legality expressions via linear or binary search, and the subsequent processing, may result in a wide range of indeterminate response times, making it impossible to meet fixed response time requirements. Conventional processing of legality expressions is not practical nor efficient in a system managing thousands or millions of legality expressions.
What is needed is a new type of system and method of efficiently processing legality expressions to meet communication requests expeditiously and in a predictable time frame.